限界上下文是领域驱动设计中的一个核心模式。它是 DDD 战略设计部分的重点，该部分主要关于处理大型模型和团队。DDD 通过将大型模型划分为不同的限界上下文并明确它们之间的相互关系来处理大型模型。

关于敏捷方法，有一个常见的误解。它集中在用户故事的创建方式以及它们在开发活动中的流动方式。误解在于，产品负责人（或业务分析师）创建用户故事，然后将它们交给开发人员去实现。这种想法是，这是一个从产品负责人到开发人员的流程，产品负责人负责确定需要做什么，而开发人员负责如何做。

当有人在寻找是什么造就了一流的企业软件开发人员时，话题往往会转向对框架和语言的了解，或者可能是理解复杂算法和数据结构的能力。对我来说，程序员或开发团队最重要的特质之一，就是我所说的“客户亲和力”。这是指开发人员对软件所要解决的业务问题以及生活在该业务领域的人们的兴趣和亲近程度。

一种由产品负责人或分析师编写故事并将其传递给开发人员构建的方法。我认为这是对敏捷思维的严重误解，因此我更喜欢对话式故事。

敏捷方法的一种常见做法，也许是占主导地位的做法，是为正在构建的软件开发一个功能列表（通常称为故事）。这些功能使用索引卡、工作队列、燃尽图、积压工作或您选择的任何工具进行跟踪。

许多公司喜欢签订固定范围和价格的合同，因为他们认为这降低了他们的风险。这种幻觉认为，他们的财务义务固定在交易价格上。如果他们没有得到满意的软件，那么他们也不会有损失。

历史或多或少都是胡说八道

-- 亨利·福特

我最近收到了一封来自《UML精粹》读者的不愉快邮件。当一位愤怒的读者后悔买了我的书，更不用说读了我的偶尔的智慧之言时，我的日子就不好过了。但这位读者的抱怨中有一些特别有趣的地方。他具体的抱怨是关于我“不必要”的历史。

需求是在开始构建产品之前应该发现的东西。在构建过程中，或者更糟糕的是，在客户开始使用您的产品时才发现需求，成本高昂且效率低下，以至于我们假设任何一个头脑清醒的人都不会这样做，因此不再赘述。

-- 苏珊娜和詹姆斯·罗伯逊

敏捷方法通过打算在构建过程中和交付后发现“需求”来违反这一基本假设。但即使是对上述圣人建议的这种漫不经心的漠视，与如今许多领先网站的做法相比也相形见绌。这些网站通过观察用户在其网站上的行为来探索需求，并利用这些信息按照以下思路生成新功能的想法

现场客户是极限编程的实践之一，是白皮书中提到的12种实践之一。它说，客户应该与开发人员一起坐在他们的开放工作区，以便随时回答问题并与开发团队互动。事实上，他们是开发团队的一部分，并且认识到团队的成功既取决于他们，也取决于开发人员。他们不必为了做到这一点而放弃他们的日常工作，但他们必须亲自到场。

敏捷开发的一个关键特性是弄清楚如何让一个系统只使用一小部分功能就能上线运行。我们构建软件是为了它提供的商业价值，我们上线的速度越快，我们就越快获得至少一部分商业价值。

敏捷开发的基本原则之一是，需求变化不仅是预料之中的，而且是受欢迎的。当一家外部公司（如Thoughtworks）为客户工作时，这将构成一个特殊的挑战。许多客户希望采用固定价格的安排，这实际上是固定范围，因为他们看到了固定范围的幻觉。但是，固定范围的合同与敏捷开发完全不符，那么像我们这样的公司该怎么办呢？

2002年，我参加了XP/敏捷宇宙大会的一个研讨会，当时“实例化需求”这个词让我印象深刻，它可以用来描述测试在XP中的一个作用。

最近，我听到了一些关于为使用极限编程计划方法的多个团队制定标准故事点机制的问题。他们希望让几个团队都使用相同的故事情节，这样，一个团队的三个故事点的努力与另一个团队的三个故事点的努力是一样的。

我认为，试图做到这一点，往好了说是价值有限，往坏了说是危险的。

在过去几年中，移动应用程序一直是软件开发领域的热门话题。像许多软件交付公司一样，Thoughtworks 收到了许多客户的请求，要求我们为他们构建移动应用程序。然而，大多数情况下，当一家公司要求我们（或任何人）构建移动应用程序时，他们一开始就走错了路。我认为，在大多数情况下，即使您希望用户与移动设备进行交互，您也应该**永远不要考虑构建移动应用程序**。相反，您需要考虑构建一个可以在多种设备上呈现的单一应用程序：移动设备、台式机、平板电脑——或者您的用户可能使用的任何设备。

用例是一种组织和获取需求的技术。它们最初是由 Ivar Jacobson 在 20 世纪 80 年代末和 90 年代初推广的。

用例和 XP 的用户故事之间有什么区别？

用户故事是软件系统所需行为的块。它们在敏捷软件方法中被广泛使用，用于将大量功能划分为更小的部分，以便于计划。您还会听到将相同的概念称为“特性”，但“故事”或“用户故事”一词如今在敏捷圈中已经很普遍了。